<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
	<TITLE>Dataxi-kone HOWTO</TITLE>
	<META NAME="GENERATOR" CONTENT="OpenOffice.org 1.0.2  (Linux)">
	<META NAME="CREATED" CONTENT="20030716;8594200">
	<META NAME="CHANGED" CONTENT="20030716;9334000">
	<META NAME="CLASSIFICATION" CONTENT="Dataxi kone reference">
	<META NAME="DESCRIPTION" CONTENT="Dataxi-kone HOWTO">
	<META NAME="KEYWORDS" CONTENT="dataxi kone">
	<META NAME="resource-type" CONTENT="document">
	<META NAME="distribution" CONTENT="global">
</HEAD>
<BODY LANG="en-GB">
<H1 ALIGN=CENTER>Dataxi-kone HOWTO</H1>
<ADDRESS STYLE="margin-bottom: 0.5cm; text-align: center">by Jyry
Kuukkanen</ADDRESS>
<P>This<SPAN LANG="en-US"> document </SPAN>is far from complete. 
</P>
<H3>1. Introduction</H3>
<H3>1.1 What is Dataxi-kone? 
</H3>
<P>Dataxi-kone is a middle server that serves clients for their
request to the database. Instead of sending a SQL clauses to the
kone, client sends a request to read, write, delete, lock and so on
accompanied with a description of the data structure that is to be
read or modified. Sounds complicated? Should not, as it is simple and
makes perfect sense. 
</P>
<P>All in all. A clients sends a request to kone, kone builds the
required SQL clauses, sends them to the database and the result is
passed back to the client. 
</P>
<P>Kone offers user validation, transaction handling, automatic
lock-control and much more. 
</P>
<H3>1.2 What is Dataxi set? 
</H3>
<P>As the name implies,<SPAN LANG="en-US"> it </SPAN>is a set of
data. Think of an CD album data structure wise. An album has an
unique ID to identify it. The main (master) table includes name,
author id and the year when published. Sub (details) table holds the
tracks, each having the album ID, track no., track name and duration.
</P>
<H4>Main table:</H4>
<TABLE BORDER=1 CELLPADDING=3 CELLSPACING=2>
	<TR>
		<TH>
			<P ALIGN=LEFT>AlbumID</P>
		</TH>
		<TH>
			<P ALIGN=CENTER>ArtistID</P>
		</TH>
		<TH>
			<P ALIGN=CENTER>Album name</P>
		</TH>
		<TH>
			<P ALIGN=CENTER>Year published</P>
		</TH>
	</TR>
	<TR>
		<TD>
			<P ALIGN=CENTER>077778600824</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>Mike Oldfield</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>Hergest ridge</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>1974</P>
		</TD>
	</TR>
</TABLE>
<H4>Sub-table:</H4>
<TABLE BORDER=1 CELLPADDING=3 CELLSPACING=2>
	<TR>
		<TH>
			<P ALIGN=CENTER>AlbumID</P>
		</TH>
		<TH>
			<P ALIGN=CENTER>TrackNo</P>
		</TH>
		<TH>
			<P ALIGN=CENTER>Track name</P>
		</TH>
		<TH>
			<P ALIGN=CENTER>Duration</P>
		</TH>
	</TR>
	<TR>
		<TD>
			<P ALIGN=CENTER>077778600824</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>1</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>Part one</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>21:40</P>
		</TD>
	</TR>
	<TR>
		<TD>
			<P ALIGN=CENTER>077778600824</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>2</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>Part two</P>
		</TD>
		<TD>
			<P ALIGN=CENTER>18:51</P>
		</TD>
	</TR>
</TABLE>
<P>In this example case both main and sub-table have four columns,
total of eight. Sub-table <I>columns each have two rows</I>, where as
in the main table there are only one row in each. Sub-table column
row count may vary, but main the table always contains no more than
one row per column. 
</P>
<P>Basic relational database principle: main and sub-table have a
relation where each main table row can be related to none, one or
more rows in sub-tables, but each sub-table row can only be related
to one row in the main table. This is normalisation rule no. 3. 
</P>
<P>Now, if you have used to thinking relations row-way, forget it.
Think column-way and only column-way. Isn't it more convenient to
think &quot;Column X in album Y has values 'Part one' and 'Part two&quot;'
than &quot;Row 1 in table Y (that has a relation 1 to many with table
Z) has value 1 in column 'Trackno', value....&quot; 
</P>
<P><SPAN LANG="en-GB">Dataxi set</SPAN> is really nothing more than a
set of columns, each having any number of values, accompanied by a
description of the structure how these columns relate to each other.
Brilliant and simple, isn't it? 
</P>
<H3>1.3<SPAN LANG="en-GB"> Dataxi set </SPAN>structure 
</H3>
<P><SPAN LANG="en-GB">Dataxi set</SPAN> structure is build up from
two sections: table and column definition. 
</P>
<P>The table section<SPAN LANG="en-GB"> basically </SPAN>describes
each table's key column and relations to other tables. 
</P>
<P>The column section describes each column used in<SPAN LANG="en-GB">
Dataxi set </SPAN>and<SPAN LANG="en-GB"> their data types. </SPAN>
</P>
<P>The structure is passed to kone in textual form and it uses simple
&quot;[section] key={ subkey1=subvalue1 subkeyN=subvalueN }&quot;
format. Space, carriage return, linefeed and tab characters are all
considered line delimiter, so any of those can be used to delimit
fields, lines, from another. Each key={ } forms a value-set that
contains one or more sub-key/sub-value pairs. 
</P>
<P>N.B. Both A value set start &quot;key={&quot; and end &quot;}&quot;
markers must be surrounded by white space, so &quot;key={subkey=value}&quot;
is not valid as there is no white space after &quot;{&quot; and
before &quot;}&quot;. 
</P>
<H4>1.3.1 Table section 
</H4>
<P>Section begins with &quot;[dztables]&quot; and is followed by
value sets for each table. 
</P>
<P>The<SPAN LANG="en-GB"> first </SPAN>table declared is considered
as the master table. The might be other tables parallel to it, but
the first one is always the only master and other tables are always
in relation to it. 
</P>
<P>A simple example: 
</P>
<PRE STYLE="margin-left: 1cm; margin-right: 1cm">albums={ alias=a key=ano:int }
tracks={ alias=t key=$albums:ano/albumno,trackno:int }  </PRE><P>
This would declare master table &quot;albums&quot; and the second
level, details table &quot;tracks&quot;. &quot;tracks&quot; depends
on &quot;albums&quot; and the &quot;ano&quot; key in &quot;albums&quot;
is called &quot;albumno&quot; in &quot;tracks&quot;. 
</P>
<P>More complex example: 
</P>
<PRE STYLE="margin-left: 1cm; margin-right: 1cm">customers={ alias=c key=cno:int }
cust_memos={ alias=cm key=$customers }
cust_people={ alias=cp key=$customers:cno/custno,rowno:int:$auto }
cust_contacts={ alias=cc key=$cust_people:rowno/personno,rowno:int:$auto }</PRE><P>
As in the simple example, &quot;customers&quot; is declared as master
table. &quot;cust_memos&quot;, that could contain only one data
column, memo type, is at the parallel to &quot;customers&quot;
sharing the same key column structure and column names. &quot;cust_memos&quot;
is<SPAN LANG="en-GB"> dependent </SPAN>on &quot;customers&quot; the
same way as &quot;tracks&quot; is to &quot;albums&quot; in the simple
example. &quot;cust_contacts&quot; is at the third level and hence
dependent on second level table &quot;cust_people&quot;. This
structure enables to have one-to-many relation between &quot;customers&quot;
and &quot;cust_people&quot;, but also the same for &quot;cust_people&quot;
and &quot;cust_contacts&quot; so that each customer can have any
number of people listed and any of these people can have any number
ways to contact (phone, email, fax etc.) 
</P>
<P>There is no limit how many levels and tables one wants to add to
the structure. The last key column, how ever, in any detail level
table must be of type integer. To make life a lot easier, the default
value can be set to &quot;$auto&quot; so that Dataxi handles the
index numbering by itself. 
</P>
<H5>alias 
</H5>
<P>Alias specifies an alternative name for the table. 
</P>
<P>Normally this is a shorter, one or two letter abbreviation of the
table name. The shorter the better as column declarations on a Dataxi
form always require a reference to a table. When the form is
designed, it looks a lot more readable when
&quot;normal_long_table_name.columnname&quot; are replaced with
&quot;alias.columnname&quot;. The form also looks more like the end
result, when short alias names are used. 
</P>
<P>Alias is simply specified as &quot;alias=x&quot;. 
</P>
<H5>key 
</H5>
<P>This specifies the key column(s) of the table. 
</P>
<P>Main tables often have only one key, but detail tables most
certainly have two or more. The format is
&quot;key=col_name:datatype:default for the master table and for
others
key=$master_table_name[:master_col_name/local_col_name][,additional_key_col:datatype]&quot;.</P>
<P>The &quot;master_col_name&quot; is the column name in the master
table and &quot;local_col_name&quot; it's<SPAN LANG="en-GB">
equivalent </SPAN>in detail table. Only those columns needs to be
listed where the column names are not the same in both tables. There
is also no need to define datatype for columns that has their
datatypes defined in the master table. Just<SPAN LANG="en-GB"> simple
</SPAN>master_name/local_name is enough. 
</P>
<P>The<SPAN LANG="en-GB"> data type </SPAN>is one of &quot;int&quot;,
&quot;dec&quot;, &quot;date&quot;, &quot;time&quot;, &quot;datetime&quot;
and &quot;text&quot;. &quot;text&quot; is the default type, so a
column without a<SPAN LANG="en-GB"> data type </SPAN>is considered
&quot;text&quot;. 
</P>
<P>Each value set key is a name of a table in the database. And each
value set consists of sub-keys &quot;key&quot; and optionally
&quot;alias&quot;. 
</P>
<H4>1.3.2 Sorting section 
</H4>
<P>Section begins with [sorting] and is followed by a list of column
name and direction &quot;asc&quot; or &quot;desc&quot; declarations. 
</P>
<P>Then building the SQL-query, this section specified in which order
the result set is returned. 
</P>
<P>The format is &quot;alias.columname=asc|desc&quot;. Example
&quot;[sorting] foo.bar=asc foo.some_other=desc&quot;. 
</P>
<P>There may be one or more columns listed in the sorting block and
each can have either &quot;asc&quot; (a to z) or &quot;desc&quot; (z
to a).d 
</P>
</BODY>
</HTML>